[レポート] Microservices on AWS：アーキテクチャパターンとベストプラクティス #awssummit

こんにちは、菊池です。

本日は、ドイツ・ベルリンで開催中のAWS Summit Berlin 2019に参加しています。

本記事は、「Microservices on AWS: Architectural Patterns and Best Practices」のレポートです。

レベル400と、Expert向けの内容ということでしたが、立ち見も入りきれない程の超人気セッションでした。

セッション概要

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features. Customers need a set of patterns to help them identify how they can leverage AWS to deploy their microservices architectures. This session describes reusable microservices best practices and patterns that can help you recognize candidates for microservices architectures in your own organizations and understand areas of potential savings and increased agility.

スピーカーは、Sascha Moellering, AWS です。

レポート

アジェンダ

• マイクロサービスにおける設計の選択肢
• サーバーレスベストプラクティス
• コンテナベストプラクティス
• サーバーレスとコンテナの融合

マイクロサービスにおける設計の選択肢

• マイクロサービスは変更のインパクト・影響範囲を最小化し、リリース速度を向上できる
  • モノリシック：1つで全てをやる（Does everything）
  • マイクロサービス：1つのことをうまくやる（Does one thing）
• コミュニケーションは必ずAPIを経由する

AWSにおける利用可能なサービス

• コンテナ
  • Amazon ECS
  • Amazon EKS
  • AWS Fargate
• サーバーレス
  • AWS Lambda
• コンテナはポータビリティ・コントロール・エコシステムに優れる
• サーバーレス（Lambda）は Function as a Service、複数の実行モデル
• サーバーレスとは何か？
  • インフラのプロビジョニング、管理は不要
  • 自動でスケール
  • 実行した分で課金
  • 高信頼でセキュア

どれを選択すべきか？

• 全て満たすならLambda
  • デプロイパッケージが50MB以下である
  • 実行時間が15分以下でよい
  • コンテナ間の通信、集中的なストレージアクセスは不要
• そうでないならコンテナ
  • 移行性が必要、あるいはOSSファンならEKS
  • インフラの管理の十分な管理を望むならECS
  • どれでもないならFargate

もっとも重要なこと

• 本当にコンテナが必要か？
• サーバーレスのアプローチでスタートし、必要になったらコンテナに切替

サーバーレスのベストプラクティス

• Lambdaはステートレス。その原則にしたがって設計する。
  • ローカルファイルシステムや子プロセスは実行時間を超えて維持されない
• AWSクライアント、DBクライアントはハンドラのスコープ外にする
• CloudWatch Eventsによる暖機
• パッケージは最小にする
• Lamdaハンドラはコアロジックと分ける
• 環境変数を利用する
• 異なった言語の利用を試す

ストリーミングプロセッシングの例

• Firehoseのバッファサイズ、インターバルをチューニングする
• 圧縮を有効に
• ソースレコードバックアップを有効に

• Kinesis Data Streams と Lambda
  • シャード数とLambda同時実行数を一致させる
  • バッチサイズ = 最大レコード数 / Lambda実行
  • バッチサイズをあげることで、Lambda実行数を減らす
  • メモリサイズのチューニング
    • 実行時間を短縮化
  • KPLの利用

コンテナのベストプラクティス

• コンテナの最適化
  • コンテナを小さいサイズに最適化する
  • 小さいOSを選択する
  • 全ての言語で同じコンテナを利用しない
• 最適化の方法
  • マルチステージDockerビルド

コンテナとサーバーレスの融合

• DockerをLambdaに
• Lambda Layers
  • ファンクション間でコードを共有
  • 責任範囲で分割
• カスタムランタイム
  • Linux互換の実行環境
  • レイヤーとしてカスタムランタイムを配布
• AWS Lambda Container Image Converter
  • Docker Image layers を Lambda Layer に

まとめ

以上です。Lambdaよりの内容が多かった印象ですが、インフラの管理から解放されアプリケーションを小さく維持するという観点からは、まずはLambda、必要に応じてコンテナというのがよいのかもしれません。